1. Field of the Invention
The present invention relates to communications protocols. More specifically, the present invention relates to communications protocols which provide for multi-speed communications such as are employed in the Institute of Electrical and Electronic Engineers 1394 Standard and similar protocols, and to methods for providing acknowledge packets in systems implementing such communications protocols.
2. The Prior Art
The components of a computer system are typically coupled to a common bus for communicating information to one another. Various bus architectures are known in the prior art, and each bus architecture operates according to a communications protocol that defines the manner in which data transfer between components is accomplished.
The Institute of Electrical and Electronic Engineers (IEEE) has promulgated a number of different bus architecture standards, including IEEE Standard 1394-1995, entitled IEEE Standard for a High Performance Serial Bus (hereinafter referred to as 1394). A typical serial bus having architecture meeting 1394 is comprised of a multiplicity of nodes that are interconnected via point-to-point links such as cables that each connect a single node of the serial bus to another node of the serial bus. Data packets are propagated throughout the serial bus using a number of point-to-point transactions, wherein a node that receives a packet from another node via a first point-to-point link retransmits the received packet via other point-to-point links. A tree network configuration and associated packet handling protocol ensures that each node receives every packet once. The serial bus of the IEEE 1394 serial bus standard may be used as an alternate bus for the parallel backplane bus of the computer system, as a low-cost peripheral bus, or as a bus bridge between architecturally compatible buses.
The communications protocol of the IEEE 1394 serial bus standard specifies two primary types of bus accesses: asynchronous access and isochronous access. Asynchronous access may be either "fair" or "cycle-master". The cycle-master form of bus access is used by nodes that need the next available opportunity to transfer data. Isochronous access is used by nodes that require guaranteed bandwidth. The transactions for each type of bus access are comprised of at least one "subaction" wherein a subaction is a complete one-way transfer operation.
According to IEEE 1394, most asynchronous transactions are carried out in two steps. First, a source node sends a packet to a destination node. The destination node then returns an acknowledge packet to the source node. The acknowledge packets are very short, including eight data bits plus the usual 1394 packet overhead of data prefix (140 ns), data end (240 ns), plus 20 ns of dribble bits.
IEEE 1394 allows transmission of packets at a range of speeds. The 1995 standard defines operation at S100, S200, and S400 (approximately 100 Mbits/sec, 200 Mbits/sec, and 400 Mbits/sec respectively), with room for extension later. It has always been assumed that acknowledge packets will be returned at the same data rate as the packet which caused the acknowledge. Thus S100 packets cause the return of S100 acknowledge packets, S200 packets cause the return of S200 acknowledge packets, and S400 packets cause the return of S400 acknowledge packets.
The eight data bits of the acknowledge packets can require about 80, 40, or 20 ns at 100, 200, or 400 Mbits/sec operation respectively at S100, S200, and S400 speeds. Thus the total transmit time for an acknowledge packet, including data prefix, data, dribble, and end states is:
S100.apprxeq.480 ns PA1 S200.apprxeq.440 ns PA1 S400.apprxeq.420 ns
Returning acknowledge packets at the same speed as the data packet being acknowledged provides a slight saving of bandwidth; 40 or 60 ns are saved by transmitting an acknowledge packet at S200 or S400 Mbit rates rather than at the S100 rate.
The new arbitration enhancements being adopted by the 1394a committee provide some bandwidth advantages for returning acknowledge packets at lower speeds.
IEEE 1394a will allow a node to concatenate an unrelated packet onto its acknowledge packet. The unrelated packet may be at a different bit rate than the acknowledge packet to which it is concatenated.
Multi-speed concatenation is affected by backward compatibility considerations, Due to limitations of existing silicon, down-shifting from the S200 and S400 rates to the S100 rate is forbidden. All other possible transitions are allowed.
Thus, in the instance where a node wanted to concatenate an S100 packet onto its acknowledge packet, it would be prevented from doing so if the acknowledge packet had been sent at S200 or S400. Sending the acknowledge packet at S200 instead of S100 will save 40 ns or 60 ns respectively, but missing the concatenation opportunity will cost at least the time required for normal arbitration, typically hundreds of ns.
IEEE 1394a will allow a node to concatenate a packet onto a passing upward (towards the root) bound acknowledge packet. This is very similar to the acknowledge-packet concatenation mentioned previously, but it uses an acknowledge packet generated by some other node entirely. The speed-bandwidth considerations of normal acknowledge-packet concatenation apply here equally; sending an S200 acknowledge packet precludes concatenation of an S100 packet onto the acknowledge packet.
Finally, IEEE 1394a will allow nodes to begin bus arbitration as soon as an acknowledge packet is detected (i.e., transmitted, received and/or repeated), subject to some timing restrictions when a new cycle-start packet is due. See U.S. Pat. No. 5,495,481 to Duckwall describing ack acceleration.
When a high-speed packet is transmitted to a node capable only of some lower speed operation, the high-speed node squelches the data, and sends an extended data prefix, followed by data end. The low-speed node has no way to detect what sort of packet was sent. Acknowledge packet recognition is impossible. And thus it is prevented from using ack acceleration.
This last point is the most important because it does not depend on the arcane problem of backward compatibility. It has to do solely with the existence of low speed nodes on a bus. Currently only S100 and S200 devices are available in production quantities, but with time the mix will undoubtedly shift to a preference for higher speed devices such as S400 and above. High speed acknowledge packets will preclude lower speed nodes from using acknowledge acceleration.
If the lower-speed node eventually has to arbitrate normally, then it may not only add arbitration time, but also the added inefficiency of requiring an extra subaction gap. This is quite a penalty for saving a few tens of ns on the acknowledge packet itself.